@philwebb just checking, does this PR align with what was raised in #44912?

Thanks @dmitrysulman! I've merged this with one small amendment to try and also check that there's an applicationTaskExecutor bean. This should hopefully align with this code in WebFluxAutoConfiguration

I'm curious as to why only when Virtual Threads are enabled. WebFlux can be configured with a ThreadPoolTaskExecutor for blocking execution using BlockingExecutionConfigurer.setExecutor(), which should be sufficient for a RestClient.

@blake-bauman We I looked at the PR I couldn't see an obvious way to tell if the BlockingExecutionConfigurer has been called. Looking again, we might be able to do that if WebFluxConfigurationSupport.getBlockingExecutionConfigurer() wasn't final. We could then return our own subclass and get access to BlockingExecutionConfigurer.getExecutor(). I'll open a Spring Framework issue to see if that's an option.

Actually, thinking about things some more, I'm not sure we can use a hook like that since we need to make our condition decision before the BlockingExecutionConfigurer is called. Perhaps we should also offer a property to enable support. @blake-bauman, feel free to open another issue if the virtual thread support isn't going to be enough.

I think my main question is, what is the need to detect? Even if an app has Virtual Threads enabled, I don't believe the execution is offloaded to a Virtual Thread if the Controller method return type is Mono, and they try to use a RestClient. I believe that throws the same exception if they tried to use a RestClient on a non-Mono Controller method and they haven't configured the BlockingExecutionConfigurer. So, I'm mainly wondering if there's a benefit to trying to detect, or if we should just let them use it and it'll fail later without the proper setup.

(For reference, this is for apps which, for one reason or another, can't yet update to Java 21 and therefore can't enable Virtual Threads, but have used the ThreadPoolTaskExecutor for the BlockingExecutionConfigurer)

@blake-bauman I'll need to discuss this with the team again to see and with some folks that have more knowledge of the reactive stack. I've flagged this one for our next meeting.

For now, we've just copy/pasted the entire RestClientAutoConfiguration internally without the conditions in order to unblock, so that we can get the Micrometer enrichments for RestClients.